home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Secrets 4 / Hacker's Secrets 4.iso / internet / passivep.txt < prev    next >
Text File  |  1995-12-04  |  8KB  |  167 lines

  1.     Stealth Scanning - Bypassing Firewalls and SATAN Detectors
  2.     ----------------------------------------------------------
  3.  
  4.  
  5. Administrators need tools to find out what is going on in their network.
  6. Maybe an internal employee has installed a unauthorized web server and
  7. put proprietary information online allowing anyone to access it, how 
  8. does an administrator find out that there is even a web server running on
  9. their network?  Many administrators use tools called TCP Port scanners.
  10. These programs which try to connect to all possible ports on a machine
  11. find which services are running.  This information gives a network
  12. administrator better ability to understand and be aware of how his or her
  13. network is configured.  Unfortunately, this technology is a double-edge
  14. sword because intruders can scan other networks and be able to gather
  15. information that helps better mount an attack.  The intruder now knows
  16. which machines are running and what services are available.  TCP port 
  17. scanning is built into shareware auditing tools, such as
  18. ISS (Internet Security Scanner) and SATAN.  These tools were intended
  19. to help administrators correct security risks in their network, but
  20. unfortunately they are just as useful to the bad guys. 
  21.  
  22. Because TCP port scanning is like knocking on the door of many services,
  23. people have written tools like SATAN detectors which notify administrators
  24. when outside people are knocking on their network.  This has made the
  25. administrator feel like they are getting a good alarm notice if a hacker
  26. decides to attack their network.
  27.  
  28. Here is a problem that we want to educate people about and possibly
  29. come up with some better solutions to addressing this problem.
  30.  
  31. Most of the TCP port scanning technology relies on making an established
  32. connection with a port to determine if it is active or not.  Many
  33. of the SATAN/Port Scanning Detectors rely on this fact.  They record
  34. the connections and if a connection happens to a wrong port or the
  35. number of connections within a certian time reaches a threshhold, an alarm
  36. goes off.  TCP_wrappers will also keep a record of any estblished 
  37. connection which helps administrators find where an intruder came from.
  38.  
  39. One problem which exists is that intruders can scan without establishing a 
  40. connection.  There is a technique for doing a half-open scan.  The intruder
  41. can send a SYN packet that starts a connection, and if the port is active,
  42. it will respond with a SYN|ACK and the intruder records these packets,
  43. determining which ports were active now.  In a typical established
  44. connection, the host responds to the SYN|ACK to finish completing the
  45. connection.  The intruder can now send a reset packet removing from the
  46. kernel that a connection was half open.
  47.  
  48. Here's the interesting information.  ----  We do not even need to use
  49. a SYN packet to scan.  Many firewalls block outside networks from
  50. sending in a SYN packet and that stops initiating a connection.
  51. So even the half-open scan won't work past a firewall.  But we have
  52. tried other TCP flags and found many other packets will do the trick
  53. just as good, and if not better.
  54.  
  55. Here's a table of the packets and response types to determine active ports.
  56.  
  57.  
  58. Flag        Active Port Response    Non-active Port Response
  59. SYN        SYN|ACK            Reset or Nothing
  60. SYN|FIN        ACK or SYN|ACK*        Reset 
  61. ACK        Nothing            Reset
  62. 0 flag        Nothing            Reset
  63.  
  64. * Depends on the TCP implementation.  Windows 95 returned SYN|ACK while most
  65. Unix platforms return an ACK.
  66.  
  67. We have picked the most interesting flags.  You can also add URG and PUSH
  68. flags to any of the above flags and get the same response.  The SYN|FIN
  69. is an illegal type of flags that contradict themselves, but a few router based
  70. firewalls that were blocking the other type packets allow this one through. 
  71. The 0 flag packets are packets that designate the packet type as 0, which
  72. some packet filter based firewalls may allow through.
  73.  
  74. Some firewalls allow ACK packets through as well. Using these type
  75. of packets, we called this a "stealth scan" because typically most
  76. TCP port scan detectors do not catch this type of activity and the scan
  77. enables you to bypass a firewall and see what services are running on
  78. the inside machines.
  79.  
  80. Denial of Service Attacks
  81. -------------------------
  82.  
  83. In coming up with developing this code, we are able to do 2 types of
  84. denial of service attacks that people should be aware of and at some
  85. point, we need to have vendors fix the problems.
  86.  
  87. 1) By scanning with all these different types of packets, we were able
  88. to crash a few popular type routers that could not handle these packets.
  89. We reported the problem back to the vendors.
  90.  
  91. 2) By scanning with half-opens and not sending a RESET, the kernel's
  92. cache of half-open connections get full and will no longer accept any more
  93. connection.  This would be a quick and easy way to cause a high connection
  94. rate machine to no longer provide any more connections, denying anyone
  95. from access to a machine, including a Web server.
  96.  
  97.  
  98. Solutions
  99. ---------
  100.  
  101. Do not rely completely on SATAN detectors.  Most of them are designed
  102. to only signal alarms if a full established connection is made.  
  103. Courtney.pl is the only SATAN detector that we found that actually looked
  104. at the packets themselves looking for SYN packets. To detect a stealth
  105. scan, we need to come up with some heuristics for detecting an anomly
  106. of the number of reset packets generated as well.
  107.  
  108. For denial of service attacks, if a device can't handle the packets
  109. it will be up to the vendor to provide a patch to fix this.
  110.  
  111. Vendors need to look at potential solutions for half open attacks
  112. such as increasing in the kernel the number of half open connections
  113. possible, decreasing the time that the cached half opens stay in the memory,
  114. possibly logging when a particular host has filled up the half open
  115. cache and ignoring further half open packets from the offending host.
  116.  
  117. Firewalls
  118. ---------
  119.  
  120. The more secure setup of firewalls tend to be a combination of both
  121. packet filter / proxy server type firewalls that would prevent
  122. scanning past the firewall if configured properly.
  123.  
  124.  
  125. -------------------------------------------------------------------------------
  126.  
  127. Copyright
  128.  
  129. This paper is Copyright (c) 1994, 1995
  130.    by Christopher Klaus of Internet Security Systems, Inc.
  131.  
  132. Permission is hereby granted to give away free copies electronically. You may
  133. distribute, transfer, or spread this paper electronically. You may not pretend
  134. that you wrote it. This copyright notice must be maintained in any copy made.
  135. If you wish to reprint the whole or any part of this paper in any other medium
  136. excluding electronic medium, please ask the author for permission.
  137.  
  138. Disclaimer
  139.  
  140. The information within this paper may change without notice. Use of this
  141. information constitutes acceptance for use in an AS IS condition. There are NO
  142. warranties with regard to this information. In no event shall the author be
  143. liable for any damages whatsoever arising out of or in connection with the use
  144. or spread of this information. Any use of this information is at the user's own
  145. risk.
  146.  
  147. Address of Author
  148.  
  149. Please send suggestions, updates, and comments to:
  150. Christopher Klaus <cklaus@iss.net> 
  151.         of Internet Security Systems, Inc.  <iss@iss.net>
  152.  
  153. Internet Security Systems, Inc.
  154.  
  155. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the
  156. developement of security scanning software tools. Its flagship product,
  157. Internet Scanner, is software that learns an organization's network and probes
  158. every device on that network for security holes. It is the most comprehensive
  159. "attack simulator" available, checking for over 100 security vulnerabilities.
  160.  
  161. -- 
  162. Christopher William Klaus         Voice: (770)441-2531. Fax: (770)441-2431
  163. Internet Security Systems, Inc.            "Internet Scanner lets you find
  164. 2000 Miller Court West, Norcross, GA 30071   your network security holes 
  165. Web: http://iss.net/  Email: cklaus@iss.net   before the hackers do."
  166.  
  167.